【レポート】AWSでの Operational Excellence ～クラウドで回す監視と運用PDCA #AWSSummit

こんにちは、坂巻です。

2019/6/12(水)～14(金) の期間で開催されている、AWS Summit Tokyo 2019からセッションをレポートします。 本記事は「AWSでの Operational Excellence ～クラウドで回す監視と運用PDCA」のレポートになります。

セッション情報

スピーカー：石川 公基氏 （アマゾン ウェブ サービス ジャパン株式会社）

リソース監視で疲弊していませんか? アプリケーションのクラウド化にあわせて、移行後の運用についてもクラウドに適した形に変えていきましょう。Amazon CloudWatchやAWS Developer Tools のほか、AWS サポートから提供されるツールやサービスを監視・運用の見直しに活用できるポイントをご紹介します。

レポート

agenda

• ビジネスへのフォーカスを可能にするクラウド
• Operational Excellence
• クラウドにおける監視と運用のポイント

ビジネスへのフォーカスを可能にするクラウド

ビジネスにおけるガバナンスとアジリティ

• ガバナンス…設定、モニタリング、管理、レポート
• アジリティ…実験・挑戦、生産性、変化への追従

ガバナンスとアジリティはトレードオフになりがちだが、AWSを活用すれば両方を実現できる 両者をコントロールするためのAWSサービス

• 導入
• Control Tower、AWS Organizations、Well-Architected Tool..
• プロビジョニング
• CloudFormation、OpsWorks..
• 運用
• CloudWatch, CloudTrail, Systems Manager..

豊富なサービスを使いこなしていくために継続的な更新と改善が必要 ->Operational Excellence

Operational Excellence

Operational Excellenceとは

ビジネス価値を提供するためのシステムの実行とモニタリングおよび、継続的にプロセスと手順を改善すること

• 変更の管理と自動化
• イベントへの対応
• 日常業務をうまく管理するための標準の定義

改善サイクル

Operational Excellenceで定義している改善サイクル

• 準備 Prepare
• 優先事項の定義
• 運用の設計と準備
• 運用 Operate
• 健全性のチェック
• イベント対応
• 発展 Evolve
• 知見の共有

定義したもので運用を行い振り返り（発展）で次の準備に反映していくことが重要

システムのクラウドネイティブ化

• 耐障害性やトラフィックの変化に対応する弾力性を備えたシステム
• サーバレス
• マネージドサービス
• 運用もクラウドネイティブに近づける

サーバレスやクラウドネイティブにすることで従来と構成が変わるため、運用もあわせてクラウドに最適がすることが重要

クラウドにおける監視と運用のポイント

ポイント（これから話す内容）

• どのようにシステムの状態を把握しているか
• どのように運用の状態を理解しているか
• デプロイ時のリスクを低減できる方法を導入しているか

質問：システムが「健全である」ことをどのように知るか？

• インスタンスの生死確認をしている
• CPUやメモリ消費量を見ている
• リクエスト数やレスポンス時間の異常値を見ている
• リクエスト数やレスポンス時間のトレンドを見ている

ポイント１：リソースからシステム全体へのシフト

• オンプレミスではリソースの正常・異常 ≒ システムの正常・異常
• クラウドでシステムの俊敏性を向上させる
• システム不可に応じてリソースを増減させると使用状況が変化する
• 異常も自動的に修復される
• 特定のリソースに依存しない指標へのシフトが重要
• ビジネスインパクトに関連する指標を定義し共通言語に

監視やアラートの重点を徐々にシフト

• リソース異常 -> システム全体のパフォーマンス
• CloudWatch
• APIのレスポンスや、ELBのリクエスト数等、リソース固有の情報からシフトしていくことが重要

ポイント２：ビジネスと連動した基準値の設定

• 例）トラフィックのトレンド
• リアルタイムでトラッキング／CloudWatch
• CloudWatchダッシュボード
• メトリクス
• 集積して後から分析／Elasticsearch
• Kibanaで可視化
• アクセスログなど
• CloudWatch + Elasticsearchの組み合わせ

質問：システムのデプロイをどのくらい手順化しているか？

• 運用手順書をもとに作業している
• リソース構成やパッケージの配布に自動化ツールを使っている
• 以前のバージョンに容易にロールバックできるようにしている
• 上記の関連作業をすべて自動化している

ポイント３：変化の繰り返しに対応

• 自動化の効果
• 自動化によって俊敏性を高める
• ヒューマンエラーを低減する
• 自動化のレイヤを上げていくことによる効果
• 実験的な操作を可能にする
• 小さい単位でデプロイ
• 以前の状態に素早く戻せる
• 万一失敗した場合に備える ≒ 実験的な変更を可能にする

サービスの利用例

• CloudFormation／リソースプロビジョニング自動化
• CodePipeline／アプリケーション配備の自動化制御
• ElasticBeanstalk／ロールバック可能なデプロイの実践
• CodeDeploy／パッケージ配備の自動化

AWS Developers Toolsに含まれるサービス

• CodeStar（CodeCommit、CodeBuild、CodePipeline、CodeDeploy）
• AWS Cloud9
• CLI
• Tools and SDKs
• X-Ray

ポイント３：変化の繰り返しに対応

• 変化の繰り返しに強くする
• アジリティを高めるために
• 自動化によって俊敏性を高める
• ヒューマンエラーを低減する
• 自動化のレイヤを上げていくことによる効果
• 実験的な操作を可能にする
• テストの単位や更新サイクルを細かくし、小さい単位でデプロイすることで以前の状態に素早く戻せる
• 万一失敗してもすぐ戻せる

最初からこんなに既存の運用を変更できない

• 最初からすべてできている必要は無い
• オンプレとの運用のバランス、体制、クラウド化のステップの進め方はそれぞれ
• 監視方法や配布方法の変更が特に効果的なサブシステムはないか？
• システム規模が小さくても、運用部問だけでなく仮想的な横断タスクを作れるとベター
• 段階的な改善例
• 監視アラートの基準変更を検討するための例

1. サービス間ダッシュボードを眺める
2. スループットやレスポンスを示すメトリクスを集める
3. （なれてきたら）複数リソースにまたがる平均値や継続時間でアラートを設定
4. （最後に）ログ集計結果などカスタムメトリクスを登録

これができると個々のリソースに依存しない新しい指標ができているはず

Developer Toolsの一部だけ使ってみる

• 運用ツールやスクリプトをDeveloper Toolsで管理してみる
• 自作した運用ツール類を管理
• コードの管理と更新検知からの配布を自動化してみる
• ダッシュボードの設定・更新を管理する

• まずは現状の把握から始める

• 現状の運用の可視化は改善後の評価のために重要
• 性能の基準・目標、チーム体制、コスト

きっかけづくりに最適なセルフチェックツール

• Well-Architected Tool
• システム構成のベストプラクティスに基づいたセルフチェックツール
• Operational Excellence視点の9つの評価軸
• Trusted Advisor
• 現状に基づいて推奨されるベストプラクティスを提示
• 毎週 or 月に1回チェック
• 定期的な見直しのきっかけに

何から初めていいかわからない時はまずはWell-Architected Toolをつかってみよう

まとめ

Operational Excellence

• ビジネス価値にフォーカスして継続的に改善を行う

クラウドにおける監視と運用のポイント

• リソース個別からシステム全体へのシフト
• ビジネスと連動した基準値の設定
• 変化の繰り返しに対応するための自動化

現状把握から始める段階的な改善

• ツールとサービスの利用例

感想

クラウドにおける監視について振り返ることができました。個々のリソースを監視するのではなく、ELBのリクエスト数など、システム全体のパフォーマンスを監視することが、改めて重要だと思いました。Operational Excellenceの視点で、Well-Architected Frameworkを読み返してみたいと思います。